DRM Protected Content Sharing

ABSTRACT

A system and method for transmitting protected real-time content from one user to another is described. In a first aspect, a user sends a Rights Object to another user. In a second aspect, a user sends a Rights Object to another user via an intermediate server for a multiparty communication. In this second aspect, the users may be able to switch between designated Rights Objects as needed.

CROSS REFERENCE TO RELATED APPLICATION

This application is a divisional of and claims priority to co-pendingapplication Ser. No. 11/617,306, filed Dec. 28, 2006, and having thesame title, which application in its entirety is incorporated byreference herein.

FIELD OF THE INVENTION

This invention relates generally to the sharing of information.

BACKGROUND OF THE INVENTION

Content sharing between multiple users is increasing. One standard OMADRM v.2 (of Mar. 15, 2004) describes the use of Rights Objects as beingdistributable to users' devices. The users' devices with the RightsObjects may then view content provided from a central source based onthe receipt of the Rights Objects from the central source.

However, this standard does not address protected real-time multimediasharing in point-to-point and multiparty communications.

SUMMARY OF THE INVENTION

This summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This summary is not intended to identify key features oressential features of the claimed subject matter.

In a first aspect of the present invention, one or more Rights Objectsmay be transmitted between users' systems, thereby enablingpoint-to-point transmissions of protected content. The Rights Objectsmay be generated locally or received from a remote source.

In a second aspect of the present invention, one or more Rights Objectsmay be transmitted from a first user's system to other users' systemsvia a central server, thereby enabling multiparty communications usingthe protected real-time multimedia.

These and other aspects of the disclosure will be apparent uponconsideration of the following detailed description of illustrativeembodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the present invention and the potentialadvantages thereof may be acquired by referring to the followingdescription of illustrative embodiments in consideration of theaccompanying drawings.

FIG. 1 shows content from a first user being distributed to other users.

FIG. 2 shows unprotected content being transmitted from a contentprovider to a first user then to various users.

FIG. 3 shows unprotected content being transmitted from a contentprovider to various users.

FIG. 4 shows protected content being transmitted from a first user toother users in accordance with aspects of the present invention.

FIG. 5 shows protected content being transmitted from a first contentprovider to various users in accordance with aspects of the presentinvention.

FIG. 6 shows the establishment of a connection using SIP in accordancewith aspects of the present invention.

FIG. 7 shows a user transmitting a Rights Object to another user inaccordance with aspects of the present invention.

FIG. 8 shows a user transmitting a locally generated Rights Object toanother user in accordance with aspects of the present invention.

FIG. 9 shows a user transmitting a Rights Object to other users via acentral server or Media Control Unit in accordance with aspects of thepresent invention.

FIG. 10 shows an illustrative example of a user device that may be usedin combination with one or more aspects of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

The various aspects summarized previously may be embodied in variousforms. The following description shows by way of illustration of variouscombinations and configurations in which the aspects may be practiced.It is understood that the described aspects and/or embodiments aremerely examples, and that other aspects and/or embodiments may beutilized and structural and functional modifications may be made,without departing from the scope of the present disclosure.

It is noted that various connections are set forth between elements inthe following description. It is noted that these connections in generaland, unless specified otherwise, may be direct or indirect and that thisspecification is not intended to be limiting in this respect.

OMA DRMv2.0 introduces the concept of Domains that can be used forinteractive sharing of content in a conference call. An OMA DRMv2.0domain is a set of devices that possess a common Domain key provisionedby a Rights Issuer (which may or may not be a content provider). Thedevices belonging to a domain can share a Domain Rights Object (RO)protected by the Domain key. The Domain RO defines the constraintsregarding the content that can be shared among the devices belonging tothe domain. Thus, devices in a Domain may share Domain Rights Objectsand are able to consume and share any DCFs controlled by Domain RightsObjects. The OMA DRM domain concept is network centric. Here, a rightsissuer (RI) defines the Domains, manages the Domain keys, and controlswhich and how many Devices are included and excluded from the Domain. Auser may request to add a device to a Domain before acquiringDomain-bound content (MUST for real-time content), or make theserequests incrementally after receiving Domain-bound content (Nonreal-time content).

OMA DRMv2.0 Domain concept can be used to support content sharing in aconference call. It can be achieved as follows:

-   -   a. The content to be shared is protected using CEK (content        encryption key). The CEK along with associated rights are        packaged in Domain Rights Object (DRO). The CEK in the DRO is        protected using domain key;    -   b. The DRO associated with the content is distributed by the        user who shares the media (in the following examples, user 1);        and    -   c. Other participants who belong to the domain are able to        decrypt the stream and follow the content usage rights. If they        do not belong to the domain, they can initiate the join domain        procedure.

The following described mechanism uses OMA DRMv2.0 domain mode ofoperation and SIP protocol to share protected content in apoint-to-point and multiparty conferencing environment.

The following abbreviations are used herein:

-   -   OMA Open Mobile Alliance    -   DRM Digital Rights Management    -   RO Rights Object    -   SDP Session Description Protocol    -   RTP Real Time Protocol    -   SSRC Synchronization Source    -   CSRC Contributing Source    -   MCU Media Control Unit

FIG. 1 shows content from a first user being distributed to other users.FIG. 1 shows a user 1 101 with unprotected (non-DRM) content. The user 1101 is connected to a network 103 via an access point 102. The accesspoint may be a wired or wireless access point as is appreciated in theart. FIG. 1 also shows additional users (user 2-3 104, 106) connectedthrough access points as well 105, 107. Content Provider 1 108 andContent Provider 2 111 are connected to network 103 via access points110 and 113, respectfully. One or more of the devices or servers shownin FIG. 1 may have one or more inputs, one or more outputs, one or moreprocessors, and one or more storage devices, as is known in the art tobe able to exchange information and transfer objects as describedherein. For purposes of explanation, the various end users'devices aredescribed as “users” as the devices enable the use of content by an enduser. It is appreciated that the devices are able to at least receiveand handle Rights Objects as described herein.

Here, a user 1 101 may transmit unprotected content to user 2 104 anduser 3 106 As shown by arrows 114 and 115.

FIG. 2 shows unprotected content being transmitted from a contentprovider to a first user then to various users. Here, content provider 1108 transmits non-DRM content 109 to user 1 101 first as shown by arrow201, who then may subsequently forward (arrows 202 and 203) the non-DRMcontent to users 2 104 and 3 106 as shown with respect to FIG. 1.

FIG. 3 shows unprotected content being transmitted from a contentprovider to various users. User 1 101 transmits instructions 301 tocontent provider 1 108 to transmit non-DRM content 109 to users 1 101, 2104, and 3 106. Next, as shown by arrows 302, 303, and 304, the non-DRMcontent is provided to users 1 101, 2 104, and 3 106.

FIG. 4 shows protected content being transmitted from a first user toother users in accordance with aspects of the present invention. User 1101 includes DRM content. The DRM content may have been created by user1 101 or have been received from a remote source. Here, user 1 101transmits a Rights Object to users 2 104 and 3 106 that permit users 2and 3 to view the DRM-content. If the Rights Object is not transmittedby user 1 101 or is not accepted by the users 2 104, 3 106, then theusers may not be able to view the DRM-content as shown by DRMprotections 401, 403, and 405.

FIG. 5 shows protected content being transmitted from a first contentprovider to various users in accordance with aspects of the presentinvention. Content Provider 2 111 transmits DRM content 112 to users 1101, user 2 104, and user 3 106. Here, the Rights Object for DRM contentmay have been already transmitted from user 1 101 to the other users. Ifthe Rights Object was not previously transmitted by user 1 101 or is notaccepted by the users 2 104, 3 106, then the users may not be able toview the DRM-content as shown by DRM protections 503 and 505.

FIG. 6 shows the establishment of a connection using SIP in accordancewith aspects of the present invention. FIG. 6 shows a conventionalINVITE/200OK procedure using session initiation protocol with variousRights Objects being able to be transmitted between users. User 1 601sends an INVITE to SIP Proxy 1 602, who then accepts the INVITE via 200OK message. The SIP Proxy 1 602 then sends the INVITE (or a relatedINVITE) to SIP Proxy 2 603. SIP Proxy 2 603 then accepts the INVITE via200 OK message. Next, the SIP Proxy 2 603 sends the INVITE (or anotherrelated INVITE) to user 2 604. User 2 604 then accepts the INVITE andsends back 200 OK message. Through this procedure, an in-call signalingpath is established. It is appreciated that the various components mayor may not acknowledge the receipt of the 200 OK messages via an ACKmessage as shown by dashed lines in FIG. 6.

FIG. 7 shows a user transmitting a Rights Object to another user inaccordance with aspects of the present invention. Here, third-partycontent is shared by User 1 702.

User 1 702 wants to share a file he received from a third-party contentprovider 701 with user 2 703. The file has been encrypted by the contentprovider in order to make sure that only users belonging to the domainare able to use the file and that they respect the usage rights. In thisregards, third-party content provider 701 sends encrypted content toUser 1 702. User 1 702 then sends an offer to join to User 2 703 wherethe offer to join also includes one or more Rights Objects.

User 1 702 starts an offer/answer with user 2 703. In the media line,User 1 702 includes the Rights Object for the DRM protected contentcorresponding to the media being protected as part of the SIP INVITE(the Offer).

Merely attempting to add the RO to the INVITE message is difficult sincethe RO is an XML object while XML cannot be included in an SDPdescription.

The following describes two approaches to this issue. First, one may useSDPng. Second, one may use the body field of the SIP INVITE message.

The IETF MMUSIC working group is developing the next generation SDPprotocol called SDPng to overcome the limitations designers andimplementers have faced in SDP. SDPng is XML based protocol so includingan RO object is straightforward. The RO object is specified using XMLand the elements can be included in the SDPng.

The RO object can be carried in the SIP message body during the sessionset up phase. When using the SIP message body, one may then correlatethe RO contained in this body with the media line the RO to which itapplies. Here, this is shown by the modified RO in FIG. 7. This may bedone by 1) declaring in the SDP media line an attribute that declaresthat the stream is protected and 2) extending the RO XML element withsome indication of the media line to which the DRM protection applies.For example, this may be done by referencing the label (a=label)attribute associated with the media line (m=) in the SDP sent by theclient.

One another way to associate the RO element in the SIP body with themedia is to create a new XML element that encapsulates the RO object andthe label attribute associated with the media in the SDP. This way thereis no need to modify the RO object. The following describes that theassociation between the media and the RO object is achieved using thelabel attribute in each media line. This could also be achieved usingthe SDP “mid” attribute which uniquely identifies a media stream.

A new mime type can to be defined for this extended RO. For descriptivepurposes, the mime type is referred to as “application/DRM-RO+xml.” Thisis included in the content-type header of the SIP messages.

The following gives an example of an SIP INVITE message with the ROattribute and the new mime type.

INVITE sip:user1@hub1.example.com SIP/2.0 Via: SIP/2.0/UDPhub3.example.com From: sip:13034513355@hub3.example.com To:sip:13039263142@hub1.example.com Call-ID:DEN1231999021712095500999@hub1.example.com CSeq: 8348 INVITE Contact:<sip:user1@example.com> Content-Length: 436 Content-Type:multipart/mixed; boundary=unique-boundary-1 MIME-Version: 1.0--unique-boundary-1 Content-Type: application/SDP; charset=ISO-10646 v=0o=user1 2890844526 2890842807 IN IP4 126.16.64.4 s=DRM seminar c=IN IP4MG122.example.com m=audio 9092 RTP/AVP 97 98 a=label:1 a=rtpmap:97AMR/8000 a=fmtp:97 octet-align=1 a=rtpmap:98 RTP.ENC.AESCM128/8000a=fmtp:98 opt=97; ContentID=″content1000221@ContentIssuer.com″; m=video5600 RTP/AVP 96 100 a=label:2 a=rtpmap:96 H263/90000 a=rtpmap:100RTP.ENC.AESCM128/90000 a=fmtp:100 opt=99;ContentID=″content6188164@ContentIssuer.com″; --unique-boundary-1Content-type: application/DRM-RO+xml <DRM-RO> <Media label=”1”type=”audio” />  <Actual DRM Object >  </Actual DRM Object> </DRM-RO>--unique-boundry-1 <DRM-RO> <Media label=”2” type=”video” />  <ActualDRM Object>  </Actual DRM Object </DRM-RO> --unique-boundry-1In the above example, user 1 702 sends an SIP INVITE message with audioand video media. Both the audio and video media are DRM protected. Inthe media line 2 payload types are declared indicating that the sendercould either send encrypted or un-encrypted data. The media streams areidentified by their label attribute. The content-type header indicatesthat this is an multipart/mixed MIME message. The INVITE message bodyconsists of two DRM-RO object corresponding to the audio and the videomedia. The DRM-RO object encapsulates the RO object and the mediaattribute.

When user 2 703 receives this SIP INVITE message, it knows from the SDPthat both the audio and the video media streams are protected and thebody of the SIP body consists of the RO object. If user 2 703 wishes totake this call, it parses the body of the SIP message to extract the ROobject for each media.

The user 2 703 (answerer) needs to accept the offer for the DRMencrypted content in his answer (by accepting the offered payload type).If it also wishes to share DRM encrypted content with user 1 702, italso needs to include the RO as part of his answer. If it does acceptthe payload type but does not specify a RO, user 1 702 will send DRMprotected data to user 2 703, while user 2 703 will send non DRMprotected data to user 1 702.

In other words, the RO itself has no offer/answer implications. It isonly a declarative attribute that refers to the RO associated with theRTP stream in the sending direction.

When user 1 702 completes sharing the DRM protected file with user 2703, user 1 702 may want to start sharing another file. User 1 702 atthis point needs to update the RO. This can also be done through theoffer/answer model. User 1 702 will update its offer with the new RO.

FIG. 8 shows a user transmitting a locally generated Rights Object toanother user in accordance with aspects of the present invention. Here,the user 1 801 shares personal content with user 2 802

The difference from the preceding use case is that the content user 1801 wants to share, is not coming from a third-party. The content couldbe the live camera view from user 1 801 phone or any multimedia fileuser 1 801 would have pre-recorded. Unlike the previous use case, it islikely that the content was not authored by a content provider but byuser 1 801 himself and the objective is not to protect a third partyrights but user 1 801's content itself.

The same mechanism as in the previous use case can be done. Thedifference is only that user 1 801 needs to create the RO himself andpossibly encrypt the content on the fly as it is being sent.

User 1 801 relies on the DRM domain mechanism to make sure that user 2802 is properly authenticated and will be abiding to the RO rules.

FIG. 9 shows a user 1 901 transmitting a Rights Object to other users(user 2 903) via a central server or Media Control Unit 902 inaccordance with aspects of the present invention. Here, multiple partiesshare the DRM content. Here, a central server or media control unit 902may include one or more inputs that receive information from userdevices, one or more outputs that transmit Rights Objects and protectedcontent to user devices, and one or more storages that store one or moreRights Objects from the user devices.

In a multiparty conference session, multiple participants (user 1 901and user 2 903) are connected to a conference server or “bridge” or MCU902. Each user 901, 903 may have point-point signaling (SIP) and mediasession (RTP) session established.

One or more users may wish to share some DRM protected content with theother users. Since the content is protected, the MCU 902 will not modifythe encrypted content of the RTP packet but will just switch between thedifferent content (for example, switching between different videos).Alternatively, the MCU 902 may attempt to mix the videos. However,mixing the videos may run afoul of various DRM content provisions.

The MCU may switch between the different streams according to differentpolicies. The different policies may be based, for instance, onend-point media control (meaning each participant can send a request tothe MCU 902 to customize the media that it wants to receive from theconference server). Alternatively, the server can choose the mediastream it wants to send to all the participants (for instance, an activespeaker, moderator etc.).

Each user may perform a separate offer/answer negotiation with the MCUas described in the point-to-point DRM sharing use case.

As shown in 9, User 901 may send the extended right objects as part ofthe offer/answer for each of the media he wants to protect (similar tothe SIP INVITE message as explained above). The MCU 902 next acceptsaccept the encrypted media but will not specify any RO. This means thatthe 200 OK message from the MCU 902 to user 1 901 there is a payloadtype for the encrypted media, but the body of the 200 OK message willnot contain any RO object. The user may not consider this an errorbecause the user knows that it is joining a conference. Also, it willlearn about the specific RO object through another procedure describedbelow.

When the MCU 902 sends back 200 OK message to user 1 901, the MCU 902does not include the RO object because the MCU 902 will forward to user1 901 the media of multiple other users who have each encrypted theirown media according to their own right objects. Accordingly, as the user1 901 needs access to other media, it will receive the Rights Objects indue course. This notification can be solved through SIPSubscribe/Notification mechanism as explained below.

As with SIP, users in a conference subscribe to the conference stateusing a SUBSCRIBE method of SIP. Conference state changes are notifiedto the participants using SIP NOTIFY.

For instance, user 1 901 has joined the conference and has signaled hismedia Right Objects to the MCU as part of the offer/answer. Next, user 2903 joins the conference. User 2 903 be notified by the MCU 902 thatuser 1 901 is in the conference. This notification can be extended withuser 1 901's ROs. This can be done by inserting the RO XML in theconference-info/users/user/endpoint/media information of thenotification which is defined inhttp://www.ietf.org/internet-drafts/draft-ietf-sipping-conference-package-12.txt.

In the IETF drafthttp://www.ietforg/internet-drafts/draft-ietf-sipping-conference-package-12.txt,the conference state is notified using XML. The media element in theconference state specifies the end point (or end user) media streamscharacteristics like media type, SSRC, label etc. The followingdescribes that the media XML element can be extended to have anothersub-element called DRM-RO. This element specifies the RO objectassociated with that media. This sub-element is an optional element inthe media element, hence where there is no encryption the DRM-ROsub-element would not be present.

The media element from the conference package draft may be as presentedbelow.

<media id=“1”> <display-text>main audio</display-text><type>audio</type> <label>34567</label> <src-id>534232</src-id><status>sendrecv</status> </media>This media element can be extended with the RO object as

<media id=“1”> <display-text>main audio</display-text><type>audio</type> <label>34567</label> <src-id>534232</src-id><status>sendrecv</status> <DRM-RO> (An example Domain RO is illustratedbelow) ...... </DRM-RO> </media>

The conference server 902, when it sends the notification message, mayinclude the RO object with the corresponding media. The MCU or theconference server 902, when it receives the SIP INVITE message from eachparticipant 901, 903, it parses the SIP body and extracts the RO objectfor each corresponding media which is co-related using the labelattribute. When the MCU 902 sends the conference state in the NOTIFYmessage, it includes the RO object for the corresponding media in themedia element as described above.

The remaining step is the application of the correct RO to decrypt anincoming packet from the MCU 902. In other words, a participant canfirst identify from which participant the RTP packet comes from andapply the correct RO for this participant. This can be done by using theRTP CSRC field.

When the MCU 902 forwards media from user 1 901 to user 2 903, itcreates a new RTP packet with the MCU SSRC but includes the SSRC of user1 901 as the only CSRC in the CSRC list. Also through the notificationmessage from the MCU, each participant is aware of the SSRC of eachmedia sender i.e., SSRC of each media stream which an end user issending. Thus user 2 903 is aware of SSRC of each of the media stream ofuser 1 901. Thus when MCU is sending the video of user 1 901 to user 2903, it would include the SSRC of the MCU as the SSRC and the SSRC ofthe user 1 901 as the CSRC. When user 2 903 receives this RTP packet, itcorrelates the CSRC to this list of SSRC it has already created throughthe notification. Based on that it can use the correct RO object (if themedia is encrypted) to decrypt the media.

As in the point-to-point use case, not only can this mechanism be usedto protect third party content but also content that would beunprotected on the user phone or the real-time content captured by thelive camera/microphone.

The following provides an example of a Domain Rights Object that may beused in accordance with one or more aspects of the present invention.

Domain RO Example

<roap:protectedRO xmlns:roap=“urn:oma:bac:dldrm:roap-1.0”xmlns:ds=“http://www.w3.org/2000/09/xmldsig#”xmlns:xenc=“http://www.w3.org/2001/04/xmlenc#”xmlns:o-ex=“http://odrl.net/1.1/ODRL-EX”xmlns:o-dd=“http://odrl.net/1.1/ODRL-DD”xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”> <roap:roid=“n8yu98hy0e2109eu09ewf09u” domainRO=“true” version=“1.0”riURL=“http://www.ROs-r-us.com”> <riID> <keyIdentifierxsi:type=“roap:X509SPKIHash”> <hash>aXENc+Um/9/NvmYKiHDLaErK0fk=</hash></keyIdentifier> </riID> <rights o-ex:id=“REL1”> <o-ex:context><o-dd:version>2.0</o-dd:version> <o-dd:uid>RightsObjectID</o-dd:uid></o-ex:context> <o-ex:agreement> <o-ex:asset> <o-ex:context> <o-dd:uid>ContentID</o-dd:uid> </o-ex:context> <o-ex:digest> <ds:DigestMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#sha1”/> <ds:DigestValue>bLLLc+Um/5/NvmYKiHDLaErK0fk=</ds:DigestValue></o-ex:digest> <ds:KeyInfo>  <xenc:EncryptedKey> <xenc:EncryptionMethodAlgorithm=“http://www.w3.org/2001/04/xmlenc#kw- aes128”/>  <ds:KeyInfo><ds:RetrievalMethod URI=“#K_MAC_and_K_REK”/> </ds:KeyInfo><xenc:CipherData>  <xenc:CipherValue>EncryptedCEK</xenc:CipherValue></xenc:CipherData>  </xenc:EncryptedKey> </ds:KeyInfo> </o-ex:asset><o-ex:permission> <o-dd:play/> </o-ex:permission> </o-ex:agreement></rights> <signature> <ds:SignedInfo> <ds:CanonicalizationMethodAlgorithm=“http://www.w3.org/2001/10/xml-exc-c14n#”/> <ds:SignatureMethod Algorithm=“http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-1#rsa-pss- default”/><ds:Reference URI=“#REL1”> <ds:Transforms> <ds:TransformAlgorithm=“http://www.w3.org/2001/10/xml-exc-c14n#”/> </ds:Transforms><ds:DigestMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#sha1”/><ds:DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</ds:DigestValue></ds:Reference> </ds:SignedInfo><ds:SignatureValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</ds:SignatureValue><ds:KeyInfo> <roap:X509SPKIHash><hash>aXENc+Um/9/NvmYKiHDLaErK0fk=</hash> </roap:X509SPKIHash></ds:KeyInfo> </signature> <encKey Id=“K_MAC_and_K_REK”><xenc:EncryptionMethod Algorithm=“http://www.w3.org/2001/04/xmlenc#kw-aes128”/> <ds:KeyInfo><roap:domainID>Domain-XYZ-001</roap:domainID> </ds:KeyInfo><xenc:CipherData><xenc:CipherValue>32fdsorew9ufdsoi09ufdskrew9urew0uderty5346wq</xenc:CipherValue></xenc:CipherData> </encKey> </roap:ro> <mac> <ds:SignedInfo><ds:CanonicalizationMethodAlgorithm=“http://www.w3.org/2001/10/xml-exc-c14n#”/><ds:SignatureMethodAlgorithm=“http://www.w3.org/2000/09/xmldsig#hmac-sha1”/> <ds:ReferenceURI=“#n8yu98hy0e2109eu09ewf09u”> <ds:Transforms> <ds:TransformAlgorithm=http://www.w3.org/2001/10/xml-exc-c14n#/> </ds:Transforms><ds:DigestMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#sha1”/><ds:DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</ds:DigestValue></ds:Reference> </ds:SignedInfo><ds:SignatureValue>j6lwx3rvEPOOvKtMup4NbeVu8nk=</ds:SignatureValue><ds:KeyInfo> <ds:RetrievalMethod URI=“#K_MAC_and_K_REK”/> </ds:KeyInfo></mac> </roap:protectedRO>

General Purpose Mobile Terminal

FIG. 10 shows an illustrative operating environment of user device 1001.User device 1001 may include processor 1002 connected to user interface1003, memory 1004 and/or other storage, and display 1005. User device1001 may also include power supply 1006 (which may include a battery orother power source), speaker 1007, and antenna(s) 1008 (representedseparately but may be combined). User interface 1003 may further includea keypad, touch screen, voice interface, one or more arrow keys,joy-stick, data glove, mouse, roller ball, touch screen, display screen,and/or other human-computer interface mechanism(s).

Computer executable instructions and data used by processor 1002 andother components within user device 1001 may be stored in a computerreadable memory 1004. The memory 1004 may be implemented with anycombination of read only memory modules or random access memory modules,optionally including both volatile and nonvolatile memory and optionallybeing detachable. Software 1009 may be stored within memory 1004 and/orother storage to provide instructions to processor 1002 for enablinguser device 1001 to perform various functions. Alternatively, some orall of the computer executable instructions of the user device 1001 maybe embodied in hardware or firmware (not shown).

User device 1001 may be configured to send and receive transmissionsbased on the Bluetooth standard, through a specific Bluetooth module1010. Additionally, user device 1001 may also be configured to receive,decode and process transmissions through FM/AM radio receiver 1011,wireless local area network (WLAN) transceiver 1012, andtelecommunications transceiver 1013. In one aspect of the invention,user device 1001 may receive radio data stream (RDS) messages. Userdevice 1001 may be equipped with additional and/or differentreceivers/transceivers, e.g., one or more of a Digital AudioBroadcasting (DAB) receiver, a Digital Radio Mondiale (DRM) receiver, aForward Link Only (FLO) receiver, a Digital Multimedia Broadcasting(DMB) receiver, etc. Each receiver may be physical or logical in thathardware may be combined to provide a single receiver that receives andinterprets multiple formats and transmission standards, as desired. Thatis, each receiver in a mobile terminal device may share parts orsubassemblies with one or more other receivers in the mobile terminaldevice, or each receiver may be an independent subassembly.

One or more aspects of the invention may be usable on any dataprocessing device on which software is validated and/or executed,including but not limited to, desktop computers, laptop and portablecomputers, personal digital assistants, smart phones, personalcommunication devices, servers, routers, and the like. Softwarevalidation and/or authentication may be accomplished, in part, throughthe use of digital signatures.

Although the subject matter has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the subject matter defined in the appended claims is notnecessarily limited to the specific features or acts described above.Rather, the specific features and acts described above are disclosed asexample forms of implementing the claims. Numerous other embodiments,modifications and variations within the scope and spirit of the appendedclaims will occur to persons of ordinary skill in the art from a reviewof this disclosure.

1. An apparatus comprising: at least one processor; and at least onememory storing computer executable instructions that, with the at leastone processor, cause the apparatus to at least: receive a first rightsobject from a first device; initiate a multiparty communication session,the multiparty communication session including the first device; andduring the multiparty communication session: receive a second rightsobject from a second device, join the second device to the multipartycommunication session, transmit the first rights object to the seconddevice, transmit the second rights object to the first device, receiveprotected content related to the multiparty communication session fromthe first device, and transmit the protected content to the seconddevice.
 2. The apparatus according to claim 1, wherein the at least onememory further stores computer executable instructions that, with the atleast one processor, cause the apparatus to: transmit the rights objectand the protected content to a third device.
 3. The apparatus accordingto claim 1, wherein the at least one memory further stores computerexecutable instructions that, with the at least one processor, cause theapparatus to: receive a third rights object from a third device; jointhe third device to the multiparty communication session; and transmit anotification to said first and second devices when the third devicejoins the multiparty communication session, the notification includingthe third rights object.
 4. The apparatus according to claim 3, whereinthe multiparty communication session is a conference, the notificationis a message related to the conference, and the protected content isreal-time protected content.
 5. The apparatus according to claim 1,wherein the at least one memory further stores computer executableinstructions that, with the at least one processor, cause the apparatusto: transmit additional protected content with an indication of whichrights object relates to said additional protected content.
 6. Theapparatus according to claim 5, wherein said indication is included in aContributing Source (CSRC) field of a real time protocol packet.
 7. Amethod comprising: receiving a first rights object from a first device;initiating a multiparty communication session, the multipartycommunication session including the first device; and during themultiparty communication session: receiving a second rights object froma second device, joining the second device to the multipartycommunication session, transmitting the first rights object to thesecond device, transmitting the second rights object to the firstdevice, receiving protected content related to the multipartycommunication session from the first device, and transmitting theprotected content to the second device.
 8. The method of claim 7,further comprising: transmitting the rights object and the protectedcontent to a third device.
 9. The method of claim 7, further comprising:receiving a third rights object from a third device; joining the thirddevice to the multiparty communication session; and transmitting anotification to said first and second devices when the third devicejoins the multiparty communication session, the notification includingthe third rights object.
 10. The method of claim 9, wherein themultiparty communication session is a conference, the notification is amessage related to the conference, and the protected content isreal-time protected content.
 11. The method of claim 7, furthercomprising: transmitting additional protected content with an indicationof which rights object relates to said additional protected content. 12.The method of claim 11, wherein said indication is included in aContributing Source (CSRC) field of a real time protocol packet.
 13. Oneor more computer readable media storing computer executable instructionsthat, when executed, cause a processor to at least: receive a firstrights object from a first device; initiate a multiparty communicationsession, the multiparty communication session including the firstdevice; and during the multiparty communication session: receive asecond rights object from a second device, join the second device to themultiparty communication session, transmit the first rights object tothe second device, transmit the second rights object to the firstdevice, receive protected content related to the multipartycommunication session from the first device, and transmit the protectedcontent to the second device.
 14. The one or more computer readablemedia of claim 13, further storing computer executable instructionsthat, when executed, cause the processor to: transmit the rights objectand the protected content to a third device.
 15. The one or morecomputer readable media of claim 13, further storing computer executableinstructions that, when executed, cause a processor to: receive a thirdrights object from a third device; join the third device to themultiparty communication session; and transmit a notification to saidfirst and second devices when the third device joins the multipartycommunication session, the notification including the third rightsobject.
 16. The one or more computer readable media of claim 15, whereinthe multiparty communication session is a conference, the notificationis a message related to the conference, and the protected content isreal-time protected content.
 17. The one or more computer readable mediaof claim 13, further storing computer executable instructions that, whenexecuted, cause the processor to: transmit additional protected contentwith an indication of which rights object relates to said additionalprotected content.
 18. The one or more computer readable media of claim17, wherein said indication is included in a Contributing Source (CSRC)field of a real time protocol packet.